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APPENDIX D — TREE META: Introduction 



1 Terms such as "metalanguage" and "metacompiler" have a variety of 
meanings. Their usage within this report, however, is well defined. 

1A "Language," without the prefix "meta," means any formal computer 
language. These are generally languages like ALGOL or FORTRAN. Any 
metalangauge is also a language. 

IB A compiler is a computer program that reads a formal -language 
program as input and translates that program into instructions that 
may be executed by a computer. The term "compiler" also means a 
listing of the instructions of the compiler. 

1C A language that can be used to describe other languages is a 
metalanguage. English is an informal, general metalanguage that can 
describe any formal language. Backus-Naur Form or BNF (Nurl) is a 
formal metalanguage used to define ALGOL. BNF is weak, for it 
describes only the syntax of ALGOL, and says nothing about the 
semantics or meaning. English, on the other hand, is powerful, yet 
its informality prohibits its translation into computer programs. 

II) A metacompiler, in the most general sense of the term, is a 
program that reads a metalanguage program as input and translates 
that program into a set of instructions. If the input program is a 
complete description of a formal language, the translation is a 
compiler for the language. 

2 The broad meaning of the word "metacompiler," the strong, divergent 
views of many people in the field, and our restricted u>e of the word 
necessitate a formal statement of the design standards and scope of Tree 
Meta. 

2A Tree Meta is built to deal with a specific set of languages and 
an even more specific set of users. This project, therefore, adds to 
the ever-increasing problem of the proliferation of machines and 
languages, rather than attempting to reduce it. There is no attempt 
to design universal languages, or machine independent languages, or 
any of the other goals of many compiler- compiler systems. 

2B Compiler-compiler systems may be rated on two almost independent 
features: the syntax they can handle and the features within the 
system that ease the compiler-building process. 

2B1 Tree Meta is intended to parse context-free laguages using 
limited backup. There is no intent or desire on the part of the 
users to deal with such problems as the FORTRAN "continue" 
statement, the PL/I "enough ends to match," or the ALGOL "is it 
procedure or is it a variable" question. Tree Meta is only one 
part of a system-building technique. There is flexibility at all 
levels of the system and the design philosophy has been to take 
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the easy way out rather than fight old problems. 

2B2 Many of the features considered necessary for a 
compiler-compiler system are absent in Tree Mefa. Such things as 
symbol -tables that handle ALGOL-style blocks and variable types 
are not included. Neither are there features for multidimensional 
subscripts or higher level macros. These features are not present 
because the users have not yet needed them. None, however, would 
be difficult to add. 

2B3 Tree Met a translates directly from a high-level language to 
machine code. This is not for the faint of heart. There is a 
very small number of users (approximately 3); all are 
machine- language coders of about the same hiph level of 
proficiency. The nature of the special -purpose languages dealt 
with is such that general formal systems will not work. The data 
structures and operations are too diverse to produce appropriate 
code with current state-of-the-art formal compiling techniques. 

3 There are two classes of formal-definition compiler-writing schemes. 

3A In terms of usage, the productive or synthetic approach to 
language definition is the most common. A productive grammar 
consists primarily of a set of rules that describe a method of 
generating all the possible strings of the language. 

3B The reductive or analytic technique states a set of rules that 
describe a method of analyzing any string of characters and deciding 
whether that string is in the language. This approach simultaneously 
produces a structure for the input string so that code may be 
compiled. 

3C The metacompilers are a combination of both schemes. They are 
neither purely productive nor purely reductive, but merge both 
techniques into a powerful working system. 

4 The metacompiler class of compiler-compiler systems may be 
characterized by a common top-down parsing algorithm and a common 
syntax. These compilers are expressible in their own language, whence 
the prefix "met a." 

4A The following is a formal discussion of top-down parsing 
algorithms. It relies heavily on definitions and formalisms which 
are standard in the literature and may be skipped by the lay reader. 
For a language L, with vocabulary V, nonterminal vocabulary N', 
productions P, and head S, the top-down parse of a string u in I, 
starts with S and looks for a sequence of productions such that S=u 
(S produces u) . 
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4A1 Let 



V - [E, T, F, ♦ , *, (, ), X.J 
N = [E, T, F) 



P = [E : 
T : 



= T / T + F 
= F / F * T 



F ::« X / ( E ) 
L = (V,N,P,E) 



4A2 The following intentionally incomplete ALGOL procedures will 
perform a top- down analysis of strings in L. 

4A2A boolean procedure E; E :~ if T then (if issymbol (•♦'• ) 
then E else true) else false; comment issymbol (arg) is a 
Boolean procedure that compares the next symbol in the input 
string with its argument, arg. If there is a match the input 
stream is advanced; 

4A2B boolean procedure T; T := if F then (if issymbol ('*») 
then T else true) else false; 

4A2C boolean procedure F; F := if issymbol ('X 1 ) then true 
else if issymbol ('» (♦) then (if E then (if issymbol (•) •) then 
true else false) else false) else false; 

4A3 The left-recursion problem can readily be seen by a slight 
modification of L. Change the first production to 

E ::= T / E + T 
and the procedure for E in the corresponding way to 

E := if T then true else if V. .... 



4A3A Parsing the string "X+X", the procedure E will call T, 
which calls F, which tests for "X" and gives the result "true." 
E is then true but only the first element of the string is in 
the analysis, and the parse stops before completion. If the 
input string is not a member of the language, T is false and E 
loops infinitely. 

4A3B The solution to the problem used in Tree Meta is the 
arbitrary number operator. In Tree Meta the first production 
could be 

E ::= T$( "+" T) 
where the dollar sign and the parentheses indicate that the 
quantity can be repeated any number of times, including 0. 

4A3C Tree Pleta makes no check to ensure that the compiler it 
is producing lacks syntax rules containing left recursion. 
This problem is one of the more common mistakes made by 
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inexperienced metalanguage programmers. 

4B The input language to the metacompiler closely resembles BNF. 
The primary difference between a BNF rule 

<go to> ::= go to <label> 
and a metalanguage rule 

GOTO * "G0 M "TO" .ID; 
is that the metalanguage has been designed to use a computer-oriented 
character set and simply delimited basic entities. The 
arbitrary-number operator and parenthesis construction of the 
metalanguage are lacking in BNF. For example: 

TERM = FACTOR $(("*" / "/" / "") FACTOR); 
is a metalanguage rule that would replace 3 BNF rules. 

4C The ability of the compilers to be expressed in their own 

language has resulted in the proliferation of metacompiler systems. 

Each one is easily bootstrapped from a more primitive version, and 

complex compilers are built with little programming or debugging 
effort. 

5 The early history of metacompilers is closely tied to the history of 
SIG/PLAN Working Group 1 on Syntax Driven Compilers. The group was 
started in the Los Angles area primarily through the effort of Howard 
Metcalfe (Schmidt 1) . 

5A In the fall of 1962, he designed two compiler-writing 
interpreters (Metcalfl). One used a bottom-to-top analysis technique 
based on a method described by Ledley and Wilson (Ledleyl). The 
other used a top-to-bottom approach based on a work by Glennie 
(Glenniel) to generate random English sentences from a context-free 
grammar. 

5B At the same time, Val Schorre described two "metamachines" — one 
generative and one analytic. The generative machine was implemented, 
and produced random algebraic expressions. Schorre implemented Meta 
I the first metacompiler, on an IBM 1401 at UCLA in January 1963 
(Schorrel). His original interpreters and metamachines were written 
directly in a pseudo-machine language. Meta I, however, was written 
in a higher- level syntax language able to describe its own 
compilation into the pseudo-machine language. Meta I is described in 
an unavailable paper given at the 1963 Colorado ACM conference. 

5C Lee Schmidt at Bolt, Beranek, and Newman wrote a metacompiler in 
March 1963 that utilized a CRT display on the time-sharing PDP-1 
(Schmidt 2). This compiler produced actual machine code rather than 
interpretive code and was partially bootstrapped from Meta I. 

6 Schorre bootstrapped Meta II from Meta I during the Spring of 1963 
(SchorreZ) . The paper on the refined metacompiler system presented at 
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the 1964 Philadelphia ACM conference is the first paper on a 
metacompiler available as a general reference. The syntax and 
implementation technique of Schorre's system laid the foundation for 
most of the systems that followed. Again the system was implemented on 
a small 1401, and was used to implement a small ALGOL-like language. 

7 Many similar systems immediately followed. 

7A Roger Rutman of A. C. Sparkplug developed and implemented LOGIK, 
a language for logical design simulation, on the IBM 7090 in January 
1964 (Rutmanl). This compiler used an algorithm that produced 
efficient code for Boolean expressions. 

7B Another paper in the 1964 ACM proceedings describes Meta III, 
developed by Schneider and Johnson at UCLA for the IBM 7090 
(Schneiderl) . Meta III represents an attempt to produce efficient 
machine code for a large class of languages. It was implemented 
completely in assembly language. Two compilers were written in Meta 
III — C0rX)L, a compiler-writing demonstration compiler, and PUREGOL, 
a dialect of ALGOL 60. (It was pure gall to call it ALGOL). The 
rumored METAE0RE, able to compile full ALGOL, has never been 
announced. 

7C Late in 1964, Lee Schmidt bootstrapped a metacompiler from the 
PDP-1 to the Beckman 420 (Schmidt3), It was a logic equation 
generating language known as EQGEN. 

8 Since 1964, System Development Corporation has supported a major 
effort in the development of metacompilers. This effort includes 
powerful metacompilers written in LISP which have extensive 
tree-searching and backup capability (Book!) (Book2). 

9 An outgrowth of one of the 0-32 systems at SDC is Meta 5 (Oppenheiml) 
(Schafferl) . This system has been successfully released to a wide 
number of users and has had many string-manipulation applications other 
than compiling. The Meta 5 system incorporates backup of the input 
stream and enough other facilities to parse any context-sensitive 
language. It has many elaborate push-down stacks, attribute setting and 
testing facilities, and output mechanisms. The fact that Meta 5 
successfully translates JOVIAL programs to PL/1 programs clearly 
demonstrates its power and flexibility. 

10 The LOT system was developed during 1966 at Stanford Research 
Institute and was modeled very closely after Meta II (Kirkleyl). It had 
new special -purpose constructs allowing it to generate a compiler which 
would in turn be able to compile a subset of PL/1. This system had 
extensive statist ic-gathering facilities and was used to study the 
characteristics of top-down analysis. It also embedded system control, 
normally relegated to control cards, in the metalanguage. 
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11 The concept of the metamachine originally put forth by Glennie is so 
simple that three hardware versions have been designed and one actually 
implemented. The latter at Washington University in St. Louis. This 
machine was built from macromodular components and has for instructions 
the codes described by Schorre (Schorre2) . 
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12 A metaprogram is a set of metalanguages rules. Each rule has the 
form of a BNF rule, with output instructions embedded in the syntactic 
description. 

12A The Tree Meta compiler converts each of the rules to a set of 
instructions for the computer. 

12B As the rules (acting as instructions) compile a program, they 
read an input stream of characters one character at a time. Each new 
character is subjected to a series of tests until an appropriate 
syntactic description is found for that character. The next 
character is then read and the rule testing moves forward through the 
input . 

13 The following four rules illustrate the basic constructs in the 
system. They will be referred to later by the reference numbers R1A 
through R4A. 

R1A KXP = TERM ("+" EXP / "-" EXP / .EMPTY); 

R2A TERM = FACTOR $('•*" FACTOR / "/" FACTOR); 

R3A FACTOR = "-" FACTOR / PRIM; 

■R4A PRIM = .11) / .NUM / "(" EXP ")"; 



13A The identifier to the left of the initial equal sign names the 
rule. This name is used to refer to the rule from other rules. The 
name of rule R1A is EXP. 

13B The right part of the rule-^everything between the initial equal 
sign and the trailing semicolon--is the part of the rule which 
effects the scanning of the input. Five basic types of entities may 
occur in a right part. Each of the entities represents some sort of 
a test which results in setting a general flag to either "true" or 
"false". 

13B1 A string of characters between quotation marks (") 
represents a literal string. These literal strings are tested 
against the input stream as characters are read. 

13B2 Rule names may also occur in a right part. If a rule is 
processing input and a name is reached, the named rule is invoked. 
R3A defines a FACTOR as being either a minus sign followed by a 
FACTOR, or just a PRIM. 

13B3 The right part of the rule FACTOR has just been defined as 
"a string of elements," "or" "another string of elements." The 
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"or's" are indicated by slash marks (/) and each individual string 
is called an alternative. Thus, in the above example, the minus 
sign and the rule name FACTOR are two elements in R3A. These two 
elements make up an alternative of the rule. 

13B4 The dollar sign is the arbitrary number operator in the 
metalanguage. A dollar sign must be followed by a single element, 
and it indicates that this element may occur an arbitrary number 
of times (including zero) . Parentheses may be used to group a set 
of elements into a single element as in R1A and R2A 

13B5 The final basic entities may be seen in rule R4A. These 
represent the basic recognizers of the metacompiler system. A 
basic recognizer is a program in Tree'.' Me ta that may be called upon 
to test the input stream for an occurrence of a particular entity. 
In Tree Meta the three recognizers are "identifier" as - .ID, 
"number" as .NUM, and "string" as .SR. There is another basic 
entity tha is treated as a recognizer but does not look for 
anything. It is .EMPTY and it always returns a value of "true." 

14 Suppose that the input stream contains the string X+Y when the rule 
EXP is invoked during a compilation. 

14A EXP first calls rule TERM, that calls FACTOR, that tests for a 
minus sign. This test fails and FACTOR then tests for a plus sign 
and fails again. Finally FACTOR calls PRIM, that tests for an 
identifier. The character X is an identifier; it is recognized and 
the input stream advances one character. 

14B PRIM returns a value of "true" to FACTOR, which in turn returns 
to TERM. TERM tests for an asterisk and fails. It then tests for a 
slash and fails. The dollar sign in front of the parenthesized group 
in TERM, however, means that the rule has succeeded because TERM lias 
found a FACTOR followed by zero occurrences of "asterisk FACTOR" or 
"slash FACTOR." Thus TERM returns a "true" value to EXP. EXP now 
tests for a plus sign and finds it. The input stream advances 
another character. 

14C EXP now calls on itself. All necessary information is saved so 
that the return may be made to the right place. In calling on itself, 
it goes through the sequence just described until it recognizes the 
Y. 

14D Thinking of the rules in this way is confusing and tedious. It 
is best to think of each rule separately. For example: one should 
think of R2A as defining a TERM to be a series of FACTORS separated 
by asterisks and slashes and not attempt to think of all the possible 
things a FACTOR could be. 
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15 Tree Meta is different from most metacompiler systems in that it 
builds a parse tree of the input stream before producing any output. 
Before we describe the syntax of node generation, let us first discuss 
parse trees. 

15A A parse tree is a structural description of the input stream in 
terms of the given grammar. 

15A1 Using the four rules above, the input stream 

X+Y*Z 

has the following parse tree 

EXP 




ACTOR 



PRIM 



15A2 In this tree each node is either the name of a rule or one 
of the primary entities recognized by the basic recognizer 
routines. 

15A3 In this tree there is a great deal of subcategorization. 
For example, Y is a PRIM, which is a FACTOR, which is the left 
member of a TERM. This degree of subcategorization is generally 
undesirable. 

15B The tree produced by the metacompiler program is simpler than 
the one above, yet it contains sufficient information to complete the 
compilation. . 
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15B1 The parse tree actually produced is 

ADD 




15B2 In this tree the names of the nodes are not the rule names 
of the syntactic definitions, but rather the names of rules that 
will be used to generate the code from the tree, 

15B3 The rules that produce the above tree are the same as the 
four previous rules with new syntax additions to perform the 
appropriate node generation. The complete rules are: 

RIB F.XP = TERM ("♦" EXP :ADD/ "-" EXP :SUB) [2] .EMPTY); 

R2B TERM = FACTOR $(("*" FACTOR :MULT/ "/" FACTOR :DIVD) 

[2]); 

R3B FACTOR = "-"FACTOR :MINUS[1] / PRIM; 
R4B PRIfl = .10 / .NUH / "(" E.XP ")"; 



15C As these rules scan an input stream, they perform just like the 
first set. As the entities are recognized, however, they are stored 
on a push-down stack until the node -generation elements remove them 
to make trees. We will step through these rules with the same sample 
input stream: 

X+Y*Z 



15C1 EXP calls TERM, which calls FACTOR, which calls PRIM, which 
recognizes the X The input stream moves forward and the X is put 
on a stack. 

15C2 PRIM returns to FACTOR, which returns to TERM, which returns 
to EXP. The plus sign is recognized and EXP is again called. 
Again EXP calls TERM, which calls FACTOR, which calls PRIM< which 
recognizes the Y. The input stream is advanced, and Y is put on 
the push-down stack. The stack now contains Y X, and the next 
character on the input stream is the asterisk. 
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15C3 PRIM returns to FACTOR, which returns to TERM. The asterisk 
is recognized and the input is advanced another character. 

15C4 The rule TERM now calls FACTOR, which calls PRIM, which 
recognizes the Z, advances the input stream, and puts the Z on the 
push -down stack. 

15C5 The :MULT in now processed. This names the next node to 
be put in the tree. Later we will see that in a complete 
metacompiler program there will be a rule named MULT which will be 
processed when the time comes to produce code from the tree. 
Next, the [2 ] in the rule TERM is processed. This tells the system 
to construct a portion of a tree. The branch is to have two 
nodes, and they are to be the last two entities recognized (they 
are on the stack). The name of the branch is to be MULT, since 
that was the last name given. The branch is constructed and the 
top two items of the stack are replaced by the new node of the 
tree. 

15C5A The stack now contains 

MULT 



15.C5B The parse tree is now 

MULT 




15C5C Notice that the nodes are assembled in a left- to-right 
order, and that the original order of recognition is retained. 

15C6 Rule TERM now returns to EXP which names the next node by 
executing the :ADD — i.e., names the next node for the tree. 
The [2] in rule EXP is now executed. A branch of the tree is 
generated that contains the top two items of the stack and whose 
name is ADD. The top two items of the stack are removed, leaving 
it as it was initially, empty. The tree is now complete, as first 
shown, and all the input has been passed over. 

16 The unparsing rules have two functions: they produce output and they 
test the tree in much the same way as the parsing rules test the input 
stream. This testing of the tree alows the output to be based on the 
deep structure of the input, and hence better output may be produced. 
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16A Before we discuss the node-testing features, let us first 
describe the various types of output that may be produced. The 
following list of output -generation features in the metacompiler 
system is enough for most examples. 

16A1 The output is line- oriented, and the end of a line is 
determined by a carriage return. To instruct the system to 
produce a carriage return, one writes a backslash (upper-case L on 
a Teletype) as an element of an unparsc rule. 

16A2 To make the output more readable, there is a tab feature. 
To. put a tab character into the output stream, one writes a comma 
as an element of an output rule, 

16A3 A literal string can be inserted in the output stream by 
merely writing the literal string in the- unparsc rule. Notice 
that in the unparsc rule a literal string becomes output, while in 
the parse rules it becomes an entity to be tested for in the input 
stream. To output a line of code which has L as a label, ADM as 
an operation code, and SYS as an address, one would write the 
following string of elements in an unparse rule: 

"L" , "ADD" , "SYS" 



16A4 As can be seen in the last example of a tree, a node of the 
tree may be either the name of an unparse rule, such as ADD, or 
one of the basic entities recognized during the parse, such as the 
identifier X. 

16A4A Suppose that the expression X+Y*Z has been parsed and 
the program is in the ADD unparse rule processing the ADD node 
(later we will see how this state is reached). To put the 
identifier X into the output stream, one tvrites "*1" (meaning 
"the first node below") as an element. For example, to generate 
a line of code with the operation code ADA and the operand 
field X, one would write: 

, "ADA", *1 



I6A4B To generate the code for the left-hand node of the tree 
one merely mentions "*l" as an element of the unparse rule. 
Caution must be taken to ensure that no attempt is made to 
append a nonterminal node to the output stream; each node must 
be tested to be sure that it is the right type before it can be 
evaluated or output. 

16AS Generated labels are handled automatically. As each unparse 



D-12 



APPENDIX D -- TREE META: Basic Syntax 



rule is entered, a new set of labels is generated. A label is 
referred to by a number sign (upper-case 3 on a Teletype) followed 
by a number. Every time a label is mentioned during the execution 
of a rule, the label is appended to the output stream. If another 
rule is invoked in the middle of a rule, all the labels are saved 
and new ones generated. When a return is made the previous labels 
are restored. 

17 As trees are being built during the parse phase, a time comes when 
it is necessary to generate code from the tree. To do this one writes 
an asterisk as an element of a parse rule — for example 

R5B PROGRAM = ".PROGRAM" $ (ST *) ".END"; 

which generates code for each statement after it has been entirely 
parsed. When the asterisk is executed, control of the program is 
transferred to the rule whose name is the root (top node or last 
generated node) of the tree. When return is finally made to the rule 
which initiated the output, the entire tree is cleared and the 
generation process begins anew. 

17A An unparse rule is a rule name followed by a series of output 
rules. Each output rule begins with a test of nodes. The series of 
output rules make up a set of highest-level alternatives. When an 
unparse rule is called, the test for the first output rule is made. 
If it is satisfied, the remainder of the alternative is executed; if 
it is false, the next alternative output rule test is made. This 
process continues until either a successful test is made or all the 
alternatives have been tried. If a test is successful, the 
alternative is executed and a return is made from the unparse rule 
with the general flag set "true." If no test is successful, a return 
is made with the general flag "false," 

17B The simplest test that can be made is the test to ensure that 
the correct number of nodes emanate from the node being processed. 
The ADD rule may begin 

ADD[-,-] => 

The string within the brackets is known as an out-test. The hyphens 
arc individual i tens of the out-test. Each item is a test for a 
node. All that the hyphen requires is that a node be present. The 
name of a rule need not match the name of the node being processed. 

17B1 If one wishes to eliminate the test at the head of the 
out-rule, one may write a slash instead of the bracketed string of 
items. The slash, then, takes the place of the test and is always 
true. Thus, a rule which begins with a slash immediately after 
the rule name may have only one out-rule. The rule 
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m I *> .EMPTY; 

is frequently used to flag the absence of an optional item in a 
list of items. It may be tested in other unparse rules but it 
itself always sets the general flag true and returns. 

17152 The nodes emanating from the node being evaluated are 
referred to as *1, *2, etc., counting from left to right. To test 
for equality between nodes, one merely writes *i for some i as 
the desired item in an out-test. Tor example, to see if node 2 is 
the same as node 1, one could write either [-,*1] or [*2,-]. To 
see if the third node is the same as the first, one could write 
[-,*2,*1]. In this case, the *2 could be replaced by a hyphen. 

17JJ3 One may test to see if a node is an element which was 
generated by one of the basic recognizers by mentioning the name 
of the recognizer. Thus to see if the node is an identifier one 
writes .ID; to test for a number one writes .NUM. To test whether 
the first node emanating from the ADD is an identifier and if the 
second node exists, one writes [.ID,-]. 

17B4 To check for a literal string on a node one may write a 
string as an item in an out-test. The construct [-,"1"] tests to 
be sure that there are two nodes and that the second node is a 1. 
The second node will have been recognized by the .NIJM basic 
recognizer during the parse phase. 

17B5 A generated label may be inserted into the tree by using it 
in a call to an unparse rule in another unparse rule. This 
process will be explained later. To see if a node is a previously 
generated label one writes a number sign followed by a number. If 
the node is not a generated label the test fails. If it is a 
generated label the test is successful and the label is associated 
with the number following the number sign. To refer to the label 
in the unparse rule, one writes the number sign followed by the 
number. 

17B6 Finally, one may test to see if the name matches a specified 
name. Suppose that one had generated a node named STORE. The left 
node emanating from it is the name of a variable and on the right 
is the tree for an expression. An unparse rule may begin as 
follows: 

STORE [-,ADD[*1,"1" ]]=>, "MIN " *1 
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The *1 as an item of the ADD refers to the left node of the 
STORE. Only a tree such as 



STORE 




.ID 



would satisfy the test, where the two identifiers must be the 
same or the test fails. An expression such as X «- X + 1 meets all 
the requirements. The code generated (for the SDS 940) would be 
the single instruction MIN X, which increments the cell X by one. 

17C Each out-rule, or highest- level alternative, in an unparse rule 
is also made up of alternatives. These alternatives are separated by 
slashes, as are the alternatives in the parse rules. 

17C1 The alternatives of the out-rule are called "out-exprs." The 
out-expr may begin with a test, or it may begin with instructions 
to output characters. Tf it begins with a test, the test is made. 
If it fails the next out-expr in the out-rule is tried. If the 
test is successful, control proceeds to the next element of the 
out-expr. When the out-expr is done, a return is made from the 
unparse rule. 

17C2 The test in an out-expr resembles the test for the out-rule. 
There are two types of these tests. 

17C2A Any nonterminal node in the tree may be transferred to 
by its position in the tree rather than its name. For example, 
*2 would invoke the second node from the right. This operation 
not only transfers control to the specific node, but it makes 
that, node the one from which the next set of nodes tested 
emanate. After control is returned to the position immediately 
following the *2, the general flag is tested. If it is "true" 
the out-expr proceedes to the next element. If it is "false" 
and the *2 is the first c lenient of the out-expr the next 
alternative of the out-expr is tried. If the flag is "false" 
and the *2 is not the first element of the out-expr, a compi ler 
error is indicated and the system stops. 

17C2J> The other type of test is made by invoking another 
unparse rule by name and testing the flag on the completion of 
the rule. To call another unparse rule from an out-expr, one 
writes the name of the rule followed by nn argument list 
enclosed in brackets. The argument list is a list of nodes in 
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the tree. These nodes are put on the node stack, and when the 
call is made the rule being called sees the argument list as 
its set of nodes to analyze. For example: 

ADD [MINUS [-].,-]. => SUB[*2,*1:*1] 

17C2B1 Only nodes and generated labels can be written as 
arguments. Nodes are written as *1, *2, etc. To reach other 
nodes of the tree one may write such things as *1:*2, which 
means "the second node emanating from the first node 
emanating from the node being evaluated." Referring to the 
tree for the expression X+Y*Z if ADD is being evaluated, 
*2:*1 is Y.To go up the tree one may write an "up arrow" ft") 
followed by a number before the asterisk-number- col on 
sequence. The uparrow means to go up that many levels 
before the search is made down the tree. If ?JULT were being 
evaluated,! 1*1 would be the X. 

17C2B2 If a generated label is written as an argument, it 
is generated at that time and passed to the called unparse 
rule so that that rule may use it or pass it on to other 
rules. The generated label is written just as it is in an 
output elcment--a number sign followed by a number. 

17C3 The calls on other unparse rules may occur anywhere in an 
out-expr. If they occur in a place other than the first element, 
they are executed in the same way, except that after the return 
the flag is tested; if it is false a compiler error is indicated. 
This use of extra rules helps in making the output rules more 
concise. 

17C4 The rest of an out-expr is made up of output elements 
appended to the output stream, as discussed above. 

17D Sopietimes it is necessary to set the general flag in an out-expr, 
just as it is sometimes necessary in the parse rules. .EMPTY may be 
used as an element in an out-expr at any place. 

171: Out-exprs may be nested, using parentheses, in the same way as 
the alternatives of the parse rules* 

18 There are a few features of Tree Meta which are not essential but do 
make programming easier for the user. 

ISA If a literal string is only one character long, one may write 
an apostrophe followed by the character rather than writing a 
quotation mark, the character, and another quotation mark. For 
example: 'S and "S" are interchangeable in either a parse rule or an 
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unparse rule. 

18B As the parse rules proceed through the input stream they may 
come to a point where they are in the middle of a parse alternative 
and there is a failure. This may happen for two reasons: backup is 
necessary to parse the input, or there is a syntax error in the 
input. Backup will not be covered in this introductory chapter. If 
a syntax error occurs the system prints out the line in error with an 
arrow pointing to the character which cannot be parsed. The system 
then stops. To eliminate this, one may write a question mark 
followed by a number followed by a rule name after any test except 
the first in the parse equations. For example: 

ST = .II) »= question 2 E EXP question 3 E •; 

question 4 E : STORE [2] ; 

Suppose this rule is executing and has called rule EXP, and EXP 
returns with the flag false. Instead of stopping Tree Meta prints 
the line in error, the arrow, and an error comment which contains the 
number 3, and transfers control to the parse rule E. 

18C Comments may be inserted anywhere in a metalanguage program 
where blanks may occur. A comment begins and ends with a percent 
sign, and may contain any character -- except, of course, a percent 
s i gn . 

18D In addition to the three basic recognizers .ID, .NUM, and .SR, 
there are two others which are occasionally very useful. 

181)1 The symbol .LET indicates a single letter. It could be 
thought of as a one-character identifier. 

181)2 The symbol . CI 1 K indicates any character. Tn the parse 
rules, .CUR causes the next character on the input stream to be 
taken as input regardless of what it is. Leading blanks are not 
discarded as for .ID, .NUM, etc. The character is stored in a 
special way, and hence references to it are not exactly the same 
as for the ether basic recognizers. In node testing, if one 
wishes to check for the occurrence of a particular character that 
was recognized by a .CUR, one uses the single quote-character 
construct. When outputting a node item which is a character 
recognized by a .CUR, one adds a :C to the node indicator. For 
example, *1:C. 

18E Occasionally some parts of a compilation are very simple and it 
is cumbersome to build a parse tree and then output from it. For this 
reason the ability to output directly from parse rules has been 
added. 
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18E1 The syntax for out put ting from parse rules is generally the 
same as for unparse rules. The output expression is written 
within square brackets, however. The items from the input stream 
that normally are put in the parse tree may be copied to the 
output stream by referencing them in the output expression. The 
most recent item recognized is referenced as * or *S0. Items 
recognized previous to that are *S1, *S2, etc., counting in 
reverse order — that is, counting down from the top of the stack 
they are kept in. 

181-2 Normally the items are removed from the stack and put into 
the tree. However, if they are copied directly to the output 
stream, they remain in the stack. They are removed by writing an 
ampersand at the end of the parse rule (just before the 
semicolon). This causes all input items added to the stack by that 
rule to be removed. The input stack is thus the same as it was 
when the rule was called. 
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19 When a Tree Meta program is compiled by the metacompiler, a 
machine- language version of the program is generated. However, it is not 
a complete program since several routines are missing. All Tree Meta 
programs have common functions such as reading input, generating output, 
and manipulating stacks. It would be cumbersome to have the 
metacompiler duplicate these routines for each program, so they are 
contained in a library package for all Tree Meta programs. The library 
of routines must be loaded with the machine- language version of the Tree 
Meta program to make it complete. 

19A The environment of the Tree Meta program, as it is running, is 
the library of routines plus the various data areas. 

19B This section describes the environment in its three logical 
parts: input, stack organization, and output. 

19R1 This is a description of the current working version, with 
some indications of planned improvements. 

20 Input Machinery 

20A The input stream of text is broken into lines and put into an 
input buffer. Carriage returns in the text are used to determine the 
ends of lines. Any line longer than 80 characters is broken into two 
lines. Hi is line orientation is necessary for the following: 

20A1 Syntax-error reporting 

20A2 A possible anchor mode (so the compiler can sense the end of 
a line) 

20A3 An interlinear listing option. 

20A4 In the future, characters for the input buffer will be 
obtained from another input buffer of arbitrary block size, but at 
present they arc obtained from the system with a Character I/O 
command. 

2QB It is the job of routine RLINE to fill the input line buffer. If 
the listing flag is on, HUNK copies the new line to the output file 
(prefixed with a comment character--an asterisk for our assembler). 
It also checks for an End-of-File, and for a multiple blank 
character, which is a system feature built into our text files. 
There is a buffer pointer that indicates which character is to be 
read from the line buffer next, and RLINE resets that pointer to the 
first character of the line. 

20C Input characters for the Tree Meta program are not obtained from 
the input line buffer, but from an input window, which is actually a 
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character ring buffer. Such a buffer is necessary for backup. There 
are three pointers into the input window. A program- character 
counter (PCC) points to the next character to be read by the program. 
This may be moved back by the program to effect backup. A 
library-character counter (LCC) is never changed except by a library 
routine when a new character is stored in the input window. FCC is 
used to compute the third pointer, the input -window pointer (TWP). 
Actually, PCC and LCC are counters, and only IWP points into the 
array RING which is the character ring buffer. LCC is never backed 
up and always indicates the next position in the window where a new 
character must be obtained from the input line buffer. Backup is 
registered in BACK, and is simply the difference between PCC and LCC. 
BACK is always negative or zero. 

20D There are several routines that deal directly with the input 
window. 

20D1 The routine PUTIN takes the next character from the input 
line buffer and stores it at the input-window position indicated 
by IWP. Tli is involves incrementing the input-buffer pointer, or 
calling RLINE if the buffer is empty. PUTIN does not change IWP. 

201)2 The routine INC is used to put a character into the input 
window. It increases IWP by one by calling a routine, UPIWP, 
which makes IWP wrap around the ring buffer correctly. If there is 
backup (i.e., if BACK is less than 0), BACK is increased by one 
and INC returns, since the next character is in the window 
already. Otherwise, LCC is increased by one, and PUTIN is called 
to store the new character. 

201)3 A routine called INCS is similar to INC except that it 
deletes all blanks or comments that may be at the current point in 
the input stream. This routine implements the comment and blank 
deletion for .ID, .NUM, .SR, and other basic recognizers. INCS 
first calls INC to get the next character and increment IWP, From 
then on, PUTIN is called to store succeeding characters in the 
input window in the same slot. As long as the current character 
(at IWP) is a blank, INCS calls PUTIN to replace it with the next 
character. The nonblank character is then compared with a comment 
character. INCS returns if the comparison fails, but otherwise 
skips to the next comment character. Mien the end of the comment 
is located, INCS returns to its blank- checking loop. 

20P3A Note that comments do not get into the input window. 
For this reason, BACK should be zero when a comment is found in 
the loop described above, and this provides a good opportunity 
for an error check. 

20D4 Before beginning any input operation, the IWP pointer must 
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be reset, since the program may have set PCC back. The routine 
WPREP computes the value of BACK from PCC-LCC. This value must be 
between and the negative of the window size. IWP is then 
computed from PCC modulo the window size. 

20D5 The program- library interface for inputting items from the 
input stream consists of the routines II), NUM, SR, LET, and CHR. 
The first four are quite similar. ID is typical of them, and 
works as follows: First MFLAG is set false. WPREP is called to 
set up IWP, then INCS is called to get the first character. If 
the character at IWP is not a letter, ID returns (MFLAG is still 
false); otherwise a loop to input over letter-digits is executed. 
When the letter-digit test fails the flag is set true, and the 
identifier is stored in the string storage area. The class of 
characters is determined by an array (indexed by the character 
itself) of integers indicating the class. Before returning, ID 
calls the routine COBL which updates PCC to the last character 
read in (which was not part of the identifier). That is, PCC is 
set to LCC+BACK-1. 

20D6 The occurrence of a given literal string in the input stream 
is tested for by calling routine TST. The character count and the 
string follow the call instruction. TST deletes leading blanks and 
inputs characters, comparing them one at a tine with the 
characters of the literal string. If at any point the match 
fails, TST returns false. Upon reaching the end of the string, TST 
sets the flag true, sets PCC to IXC+BACK, and returns. In 
addition to TST, there is a simple routine to test for a single 
character string (TCli). It inputs one character (deleting 
blanks), compares it to the given character and returns false, or 
adjusts PCC and returns true. 

21 Stacks and Internal Organization 

21A Three stacks are available to the program. A stack called 
MSTACK is used to hold return locations and generated labels for the 
program's recursive routines. Another stack, called KSTACK, contains 
references to input items. l/hen a basic recognizer is executed, the 
reference to that input i ten is pushed into KSTACK. The third stack 
is called NSTACK, and contains the actual tree. The three stacks are 
declared in the Tree Meta program rather than the library: the 
program determines the size of each. 

21A1 The operation of MSTACK is very simple. At. the beginning of 
each routine, the current generated labels and the location that 
the routine was called from are put onto "'STACK. The routine is 
then free to use the generated labels or call other routines. The 
routine ends by restoring the generated labels from MSTACK and 
returning. 



D-21 



APPENDIX n — TREE META: Program Environment 



21A2 KSTACK contains single-word entries. Each, entry will 
eventually be placed in NSTACK as a node in the tree. The format 
of the node words is as follows: There are two kinds of nodes, 
terminal and nonterminal. Terminal nodes are references to input 
items. Nonterminal nodes are generated by the parse rules, and 
have names which are names of output rules. 

21A2A A terminal node is a 24-bit word with either a 
string-storage index or a character in the address portion of 
the word, and a flag in the top part of the word. The flag 
indicates which of the basic recognizers (ID, NUM, SR, LET, or 
CI IK) is to read the item from the input stream. 
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21A2B A nonterminal node consists of a word with the address 
of an output rule in the address portion, and a flag in the top 
part which indicates that it is a nonterminal node. A node 
pointer is a word with an NSTACK index in the address and a 
pointer flag in the top part of the word. Each nonterminal 
node in NSTACK consists of a nonterminal node word followed by 
a word containing the number of subnodes on that node, followed 
by a terminal node word or node pointers for each subnode. For 
example, 



TREE 



NSTACK 



KSTACK 



ADD 




X MULT 



node ptr. 



SS item X 



node 



SS item 



node 



ADD 



SS item Y 



MULT 



node ptr. 



21A2C KSTACK contains terminal nodes (input items) and 
nonterminal node pointers that point to nodes already in 
NSTACK. NSTACK contains nonterminal nodes. 

2 IB String Storage is another stack- like area. All the items read 
from the input stream by the basic recognizers (except CUR) are 
stored in the string-storage area (SS) . This consists of a series of 
character strings prefixed by their character counts. An index into 
SS consists of the address of the character count for a string. 
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Strings in SS are unique. A routine called STORE will search SS for 
a given string, and enter it if it is not already there, returning 
the SS index of that string. 

21C Other routines perform housekeeping functions like packing and 
unpacking strings, etc. There are three error-message writing 
routines to write the three types of error messages (syntax, system, 
and compiler). The syntax error routine copies the current input 
line to the teletype and gives the line number. A routine called 
FINISH closes the files, writes the number of cells used for each of 
the four stack areas (KSTACK, MSTACK, NSTACK, and SS) , and terminates 
the program. 

21C1 At many points in the library routines, parameters are 
checked to see if they are within their bounds. The system error 
routine is called if there is something wrong. This routine 
writes a number indicating what the error is, and terminates the 
program. In the current version, the numbers correspond to the 
following errors: 

21C1A (1) Class codes are illegal 

21C1B (2) Backup too far 

21C1C (64) Character with code greater than <>3 in ring buffer 

21C1I) (4) Test for string longer than ring size 

21C1E (5) Trying to output a string longer than maximum 
string length 

21C1F (6) String-storage overflow 

21C1C (7) Illegal character code 

21C1II (8) Trying to store SS element of length zero 

21C1I (11) MSTACK overflow 

21C1..T (12) NSTACK overflow 

21C1K (13) KSTACK overflow 

2 IP There is a set of routines used by Tree Mcta that arc not. 
actually part of the library, but are loaded with the library for 
Tree Mcta. They are not included in the library since they are not 
necessarily required for every Tree Meta program, but more likely 
only for Tree Mcta. They are called "support routines." The 
routines perform short but frequently needed operations and serve to 
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increase code density in the metacompiler. Examples of the 
operations are generating labels, saving and restoring labels and 
return addresses on MSTACK, comparing flags in NSTACK, generating 
nodes on NSTACK, etc. 

Output Facilities 

22A The output from a Tree Meta program consists of a string of 
characters. In the future it might be a string of bits constituting a 
binary program, but at any rate it can be thought of as a stream of 
data. The output facilities available to the program consist of a set 
of routines to append characters, strings, and numbers to the output 
stream. 

22A1 A string in SS can be written on the output stream by 
calling the routine OUTS with the SS index for that string. OUTS 
checks the SS index and generates a system-error message if it is 
not reasonable. 

22A2 A literal string of characters is written by calling the 
routine LIT The literal string follows the call as for TST. 

22A3 A number is written using routine OUTS. The binary 
representation is given, and is written as a signed decimal 
integer. 

22A4 All of the above routines keep track of the number of 
characters written on the output stream (in CHNO) . Based on this 
count, a routine called TAB will output enough spaces to advance 
the current output line to the next tab stop. Tabs are set at 
8- character intervals. The routine CRLF will output a carriage 
return and a line feed and reset CHNO, 

22A5 There are several routines that are convenient for 
debugging. One (IVRSS) will print the contents of SS. Another 
(WRTW) will print the contents of the input window. 
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23 This chapter is a formal description of the complete Tree Meta 
language. It is designed as a reference guide, 

23A For clarity, strings that would normally be delimited by 
quotation marks in the metalanguage are capitalized instead, in this 
chapter only. 

23B Certain characters cannot be printed on the report- generating 
output media but are on the teletypes and in the metalanguage — their 
names, preceeded by periods, are used instead. They are 
.exclamation, .question, .pound, .ampersand, .backslash, and 
.percent. 

24 Programs and Rules 
24A Syntax 

24A1 program = .META .id (.LIST / .empty) size / .CONTINUE $rule 

.END; 

24A2 size = • ( siz $(», siz) •) / .empty; 

24A3 siz = .chr '= .num; 

24A4 rule = .id ('= exp (.ampersand / .empty) / •/ "«>" genl / 
outrul) • ; ; 

24B Semantics 

24B1 A file of symbolic Tree Meta code may be either an original 
main file or a continuation file. A compiler may be composed of 
any number of files but there may be only one main file. 

24B1A The mandatory identifier following the string .META in a 
main file names the rule at which the parse will begin. 

24B1B The optional .LIST, if present, will cause the compiler 
currently being generated to list input when it is compiling a 

program. 

24B1C The size construct sets the allocation parameters for the 
three stacks and string storage used by the Tree Meta library. 
The default sizes are those used by the Tree Meta compiler. M, 
K, N, and S are the only valid characters; the size is 
something that must be determined by experience. The maximum 
number of cells used during each compilation is printed out at 
the end of the compilation. 

24B2 When a file begins with .CONTINUE, no initialization or 
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storage-allocation code is produced. 

24B3 There are tliree different kinds of rules in a Tree Meta 
program. All three begin with the identifier that names the rule. 

24B3A Parse rules are distinguished by the = following the 
identifier. If all the elements that generate possible nodes 
during the execution of a parse rule are not built into the 
tree, they must be popped from the kstack by writing an 
ampersand immediately before the semicolon. 

24B3B Rules with the string / => following the identifier 
may be composed only of elements hat produce output. There is 
no testing of flags within a rule of this type. 

24I13C Unparse rules have a left bracket following the 
identifier. This signals the start of a series of node tests. 

25 repressions 

25A Syntax 

2SA1 exp = '<-suback ('/ exp / .empty) / snbexp ('/ exp / .empty); 

25A2 suback = ntest (suback / .empty) / stest (suback / .empty); 

25A3 subexp = (ntest / stest) (nob'ack / .empty); 

25A4 noback = (ntest / stest ('.question .nun (.id / '.question ) 
/ .empty) ) (noback / .empty); 

25B Semantics 

25B1 'Hie expressions in parse rules are composed entirely of 
ntest, stest, and error- recovery constructs. The four rules 
above, which define the allowable alternation and concatention of 
the test, are necessary to reduce the instructions executed when 
there is no backup o-F the input stream. 

25B2 An expression is essentially a series of subexpressions 
separated by slashes. bach subexpression is an alternative of the 
expression. The alternatives are executed in a left-to-right 
order until a successful one is found. The rest of that 
alternative is then executed and the rule returns to the rule that 
invoked it. 

25B3 The subexpressions are series of tests. Only subexpressions 
that begin with a leftarrow are allowed to back up the input 
stream and rescan it. 
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25R3A Without the arrow at the head of a subexpression, any- 
test other than the first within the subexpression may be 
followed by an error code. If the error code is absent and the 
stest fails during compilation, the system prints an error 
comment and stops. If the error code is present and the stest 
fails, the system prints the number following the '.question in 
the error code, and if the optional identifier is given the 

system then transfers control to that rule; otherwise it stops., 

i 

25B3B If the test fails, the input stream is restored to the 
position it had when the subexpression began to test the input 
stream and the next alternative is tried. The input stream may 
never be moved back more characters than are in the ring 
buffer. Normally, backup is over identifiers or words- and the 
buffer is long enough. 

26 Elements of Parse Rules 

26A Syntax 

26A1 ntest = (':.id / '[ ( .num *] / genp '] ('.backslash / 
.empty )■/ '< genp '> ('.backslash / .empty) 7 (.CUR / •*) / "=>" 
/ comm; 

26A2 genp - genpl / .empty; 

26A3 genpl = genp2 (genpl / .empty); 

26A4 genp2 = »* (S .num / .empty) (I. / C / N / .empty) / genu; 

26A5 comm = .EMPTY / '.exclamation .sr; 

26A6 stest = '. .id / .id / .sr / '( exp ' ) / " .chr / (.num '$ / 
'$) (.num / .empty) stest / '- (.sr / ".chr); 

26B Semantics 

26B1 The ntest elements of a parse mle cannot change the value 
of the general flag, and therefore need not be followed by 
flag-checking code in the compiler. 

26B1A The : .id construct names the next node to be put into 
the tree. The identifier must be the name of another rule. 

26B1B The [ .num ] constructs a node with the name used in 
the last : .id construct, and puts the number of nodes 
specified after the arrow on the new node in the tree. 

20B1C The [ genp 1 is used to write output into the normal 
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output stream during the parse phase of the compilation. 

26B1D The < penp > is used to print output back on the user 
teletype instead of the normal output stream. This is 
generally used during long compilations to assure the user that 
the system is still up and running correctly. 

26B1E The occurrence of a .chr causes one character to be read 
from the input stream into a special register which may be put 
into the tree just as the terminal symbols recognized by the 
other basic recognizers are. 

26B1F An asterisk causes the rule currently in execution to 
perform a subroutine call to the rule named by the top of the 
tree. 

26B1G The H «>" ntest construct causes the input stream to be 
moved from its current position past the first occurrence of 
the next stest. This may be used to skip over comments, or to 
move the input to a recognizable point such as a semicolon 
after a syntax error. 

26B2 The comm elements are common to both parse and unparse 
rules. 

26B2A The .EMPTY in any rule sets the general flag true. 

26B2B The .exclamation-string construct is used to insert 
patches into the compiler currently being produced. The string 
following the .exclamation is immediately copied to the output 
stream as a new line. This allows the insertion of any special 
code at any point in a program. 

26B3 Stests always test the input stream for a literal string or 
basic entity. If the entity is found it is removed from the input 
stream and stored in string storage. Its position in string 
storage is saved on a push-down stack so that the entity may later 
be added as a terminal node to the tree. 

26B3A A .id construct provides a standard machine- language 
subroutine call to the identifier. Supplied with the Tree Meta 
library are subroutines for .id, .num, .sr, .chr, and .let 
which check for identifier, number, string, character, and 
letter respectively. 

26B3B An identifier by itself produces a call to the rule with 
the name of the identifier. 

26B3C A literal string merely tests the input stream for the 
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string. If it is found it is discarded. The 

apostrophe-character construct functions like the literal 
string, except that the test is limited to one character. 

26B3D The numb er-$- number construct is the arbitrary -number 
operation of Tree Meta. m$n preceding an element in a parse 
rule means that there must be between m and n occurrences of 
the next element coming up in the input. The default options 
for m and n are zero and infinity respectively. 

26B3E The hyphen-string and hyphen- character constructs test 
in the same way as the literal string and apostrophe-character 
constructs. After the test, however, the flag is complemented 
and the input-stream pointer is never moved forward. This 
permits a test to be sure that something does not occur. 

27 Unparse Rules 

27A Syntax 

27A1 outrul = '[ outr (outrul / .empty); 

27A2 outr = items •] "=>" outexp; 

27A3 items = item (', items / .empty); 

27A4 item = '- / .id •[ outest / nsimpl / ' . .id / .sr / ' •.chr / 
'.pound; 

27B Semantics 

27B1 The unparse rules are similar to the parse rules in that 
they test something and return a true or false value in the 
general flag. The difference is that the parse rules test the 
input stream, delete characters from the input stream, and build a 
tree, while the unparse rules test the tree, collapse sections of 
the tree, and write output. 

27B2 There are two levels of alternation in the unparse rules. 
The highest level is not written in the normal style of Tree Meta 
as a series of expressions separated by slashes; rather, it is 
written in a way intended to reflect the matching of nodes and 
structure within the tree. Each unparse rule is a series of these 
highest-level alternations. The tree-matching parts of the 
alternations are tried in sequence until one is found that 
successfully matches the tree. The rest of the alternation is 
then executed. There may be further test within the alternation, 
but not complete failure as with the parse rules. 
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27B3 The syntax for a tree-matching pattern is a left bracket, a 
series of items separated by commas, and a right bracket. The 
items are matched against the branches emanating from the current 
top node. The matching is done in a left- to-right order. As soon 
as a match fails the next alternation is tried. 

27B4 If no alternation is successful a false value is returned. 

27B5 Each item of an unparse alternation test may be one of five 
different kinds of test. 

27B5A A hyphen is merely a test to be sure that a node is 
there. This sets up appropriate flags and pointers so that the 
node may be referred to later in the unparse expression if the 
complete match is successful. 

27B5B The name of the node may be tested by writing an 
identifier that is the name of a rule. The identifer must then 
be followed by a test on the subnodes. 

27BSC A nonsimple construct, primarily an 

asterisk-number-colon sequence, may be used to test for node 
equivalence. Note that this does not test for complete 
substructure equivalence, but merely to see if the node being 
tested has the same name as the node specified by the 
construct. 

27B5D The .id, .num, .chr, .let, or ,sr checks to see if the 
node is terminal and was put on the tree by a .id recognizer, 
,num recognizer, etc. during the parse phase. This test is 
very simple, for it nerely checks a flag in the upper part a 
word. 

27B5E If a node is a terminal node in the tree, and if it has 
been recognized by one of the basic recognizers in meta, it may 
be tested against a literal string. This is done by writing 
the string as an item. The literal string does not have to be 
put into the tree with a ,sr recognizer; it can be any string, 
even one put in with a .let. 

27B5F If the node is terminal and was generated by the .chr 
recognizer it may be matched against another specific character 
by writing the apostrophe-character construct as an item. 

27B5H Finally, the node may be tested to see if it is a 
generated label. The labels may be generated in the unparse 
expressions and then passed down to other unparse rules. The 
test is made writing a .pound-number construct as an item. If 
the node is a generated label, not only is this match 
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successful but the label is made available to the elements of 
the unparse expression as the number following the .pound. 

28 Unparse Expressions 

28A Syntax 

28A1 outexp = subout ('/ outexp / .empty); 

28A2 subout = outt (rest / .empty) / rest; 

28A3 rest = outt (rest / .empty) / gen (rest / .empty); 

28A4 outt = .id • [ arglst »] / f ( outexp •) / nsimpl (': (S / L / 
N / C) / empty); 

28A5 arglst « argmnt (*, arglst / .empty) / .empty; 

28A6 argmnt = nsimp / '.pound .num; 

28A7 nsimpl = * t nsimp / nsimp; 

28A8 nsimp = •* .num ( • : nsimp / .empty); 

28A9 genl = (out / comm) (genl / .empty); 

28A10 gen = comm / genu /'</'>; 

28B Semantics 

28B1 The rest of the unparse rules follow more closely the style 
of the parse rules. Each expression is a series of alternations 
separated by slash marks. 

28B2 Each alternation is a test followed by a series of output 
instructions, calls of other unparse rules, and parenthesized 
expressions. Once an unparse expression has begun executing calls 
on other rules, elements may not fail; if they do a compiler error 
is indicated and the system stops. 

28B3 The first element of the expression is the test. This 
element is a call on another rule, which returns a true or false 
value. The call is made by writing the name of the rule followed 
by a series of nodes. The nodes are put together to appear as 
part of the tree, and when the call is made the unparse rule 
called views the nodes specified as the current part of the tree, 
and thus the part to match against and process. 

28B3A Two kinds of things may be put in as nodes for the 
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calls. The simplest is a generated label. This is done by 
writing a .pound followed by a number. Only the numbers 1 and 
2 may be used in the current system. If a label has not yet 
been generated, one is made up. This label is then put into the 
tree. 

28B3B Any already constructed node also may be put into the 
tree in this new position. The old node is not removed- -rather 
a copy is made. An asterisk-number construct refers to nodes in 
the same way as the highest- level alternation. 

28B4 This process of making new structures from the 
already-existing tree is a very powerful way of optimizing the 
compiler and condensing the number of rules needed to handle 
compilation. 

28I>5 The rest of the unparsc expression is made up of output 

commands, and more calls on unparse rules. As noted above, if any 

except the first call of an expression fails, a compiler error is 

indicated and the system stops. 

28B6 Just as in the parse rules, brackets may be used to send 
immediate printout to the user Teletype. 

28B7 The asterisk-number-colon construct is used frequently in 
the Tree Met a system. It appears in the node-matching syntax as 
well as in the form of an element in the unparse expressions. 
When it is in an expression it must specify a node that exists in 
the tree. 

2SB7A If the node specified is the name of another rule, then 
control is transferred to that node by the standard subroutine 
linkage. 

28B7K If the node is terminal, then the terminal string 
associated with the node is copied onto the output stream. 

28B7C The simplest form of the construct is an asterisk 
followed by a number, in which case the node is found by 
counting the appropriate number of nodes from left to ripht. 
This may be followed by a colon-number construct, which means 
to go down one level in the tree after performing the 
asterisk-number choice and count over the number of nodes 
specified by the number following the colon. This process may 
be repeated as often as desired, and one may therefore go ar. 
deep as one wishes. All of this specification may be preceded 
by an t- number construct which means to go up in the tree, 
through parent nodes, a specified number of times before 
starting down. 
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28B7I) After the search for the node has been completed, a 

number of different types of output may be specified if the 

node is terminal. There is a compiler error if the node is not 
terminal. 

28B7D1 :s puts out the literal string 

28B7D2 :1 puts out the length of the string as a decimal 
number 

28B7D3 :n puts out the string-storage index pointer if the 
node is a string-storage element; otherwise it puts out the 
decimal code for the node if it is a .chr node. 

28B7D4 :c puts out the character if the node was 
constructed with a .chr recognizer. 

29 Output 

29A Syntax 

29A1 genu = out / '...id •] ((.id / .num) / .empty) '] / '.pound 
.num (' : / .empty) ; 

29A2 out = ('.backslash / ', / ,sr / ".chr / "«-w" / "-w" / ".w" 
/ ".pound" ; 

29B Semantics 

29B1 The standard primitive output features include the 
following: 

29B1A Write a carriage return with a backslash 

29B1B Write a tab with a comma 

29B1C Write a literal string by giving the literal string 

29B1D Write a single character using the apostrophe-character 
construct 

29B1E Write references to temporary storage by using a working 
counter. Three types of action may be performed with the 
counter. +W adds one to the counter and writes the current 
value of the counter onto the output stream. -W subtracts one 
from the counter and does not write anything. .W writes the 
current value without changing it. Finally, .pound W writes the 
maximum value that the counter ever reached during the 
compilation. 
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29B2 The .id [ (.num/.id) ] is used to generate a call (940 BUM 
instruction) with a single argument in the A register. It has 
been used mostly as a debugging tool during various bootstrap 
sessions with the system. For example, ,CFRR[5] generates a call 
to the subroutine CERR with a 5 in the A register. 

29B3 .pound 2 means "define generated label 2 at this point in 
the program being compiled." It writes the generated label in 
the output stream followed by an F.QU *. This construct is added 
only to save space and writing. 
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30 Since the work on Tree Meta is still in progress, there arc few 
conclusions and plentiful future plans. 

31 There are many research projects that could be undertaken to inprove 
the Tree Meta system. 

31A Something that has never been done, and that we feel is very 
important, is a complete study of the compiling characteristics of 
top-down analysis techniques. This would include an accurate study of 
where all the time goes during a compilation as well as a study of 
the flow of control during both parse and unparse phases for 
different kinds of compilers and languages. At the same tine it 
would be worthwhile to try to get similiar statistics from other 
compilers. It may be possible to interest some people at Stanford in 
cooperating on this. 

3 IB SPC has added an intermediate phase to their metacompiler 
system. They call it a bottom-up phase, and it has the effect of 
nutting various attributes and features on the nodes of the tree. 
This allows one to write simpler and faster node-matching 
instructions in the unparse rules. V.'e would like to investigate this 
scheme, for it appears to hold the potential for allowing the 
compiler writer to conceptualize more complex tree patterns and thus 
utilize the node-matching features to a fuller extent. 

31C Yet another intermediate phase could be added to Tree Meta which 
would do transformations on the tree before the unparse rules produce 
the final code. In attempts to write compilers in Tree Meta to 
compile code for languages with complex data structures (such as 
algebraic languages with matrix operations or string-oriented 
languages with tree operations) and to make these compilers produce 
efficient code, we have found that tree transformations similar to 
those used for natural- language translation allow one to specify 
easily and simply the rules for tree manipulation that permit the 
unparse rules to produce efficient, dense code. Implementation of 
the tree- trans format ion phase into the Tree Meta system would be an 
extensive research project, but could add a completely new dimension 
to the power of Tree Meta. 

310 There are a series of additions, some very small and some major, 
that we intend to add to Tree Meta during the next year. 

31D1 Other metacompiler systems have had a construct that allows 
nodes to have an arbitrary number of nodes emanating from them. 
This requires additions in parse rules to specify such a search, 
additions in the node-matching syntax, and additions in the output 
syntax to scan and output any number of branches. 

311)2 We have always felt that it would be nice to have the basic 
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recognizers such as "identifier" defined in the metalanguage. 
There have been systems with this feature, but the addition has 
always had very bad effects on the speed of compilation. We feel 
that this new freedom can be added to Tree Meta without having 
telling effects on the compilation speed. 

31P3 The error scheme for unparse rules is rather crudc--the 

compiler just stops. We would like to find a reasonable way of 

accommodating such errors and putting the recovery-procedure 
control in the metalanguage. 

31D4 Currently the unparse rules expand into 6 times as many 
machine-language instructions as the parse rules. This happens 
because we did not choose the most appropriate set of subroutines 
and common procedures for the unparse rules. Without changing the 
syntax of Tree Meta or the way the stacks work, we feel that we 
can reduce the size of the unparse rules by a factor of 4. This 
would free a considerably larger amount of core storage for stacks 
and enlarge the size of programs that Tree Meta could handle. It 
would also make it run faster in time-sharing mode since less 
would have to be swapped into core to run it. 

31D5 In doing some small tests on the speed of Tree Meta we found 
that better than 80 percent of the compilation time is spent 
outputting strings of characters to the system. The code that 
Tree Meta now produces is the simplest form of assembly code. It 
would be a very simple task to make Tree Meta able to directly 
produce binary code for the loader rather than symbolic code for 
the assembler. A similar change could also be made to output 
absolute code directly into core so that Tree Meta could be used 
as the compiler for systems that do incremental compilation. 

31b Finally, there is the following list of minor additions or 
changes to be made to the Tree Meta system. 

31E1 Make the library output routines do block I/O rather than 
character I/O. This could cut compilation times by more that. 70 
percent . 

31U2 Fix Tree Meta so that strings can be put into the tree and 
passed down to other unparse rules. This would allow the unparse 
rules to be more useful as subroutines and thus cut down the 
number of unparse rules needed in a conpi. ler. 

311-3 Finally, we would like to add the ability to associate a set 

of attributes with each terminal entity as it is recognized, to 

test these attributes later, and to add more or change them if 

necessary. To do this we would associate a single 24-bit word 

with the string when it is put into string storage and add syntax 
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to the metalanguage to set, reset, and test the bits of the word, 
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1 This section of the report is merely the listings of compilers for two 
languages. 

2 The first language, known as SAL for "small algebraic language," is a 
straightforward algebraic ALGOL-like language. 

3 The second example resembles Schorre's META II. This is the original 
metacompiler that was used to bootstrap Tree Meta. It is a one-page 
compiler written in its own language (a subset of Tree Meta) . 
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XTREE META SMALL ALGEBRAIC LANGUAGE - 29 SEPTEMBER 1967 % 

.META PROGRAM .LIST 

PROGRAM = "•PROGRAM" DEC * $C DEC *> :STARTNC03 ST * $(•; ST *> 

"•FINISH" ?1E JENDNC03 * FINISH 1 

DEC = ".DECLARE" .ID $( •# .ID *DOC23) '; :DECNC13; 

F = RESET => •; $CST *) ".END" ?99E JENDNC03 * FINISH; 

ST = IFST / WHILEST / FORST / GOST / 10 ST / BLOCK / 

• ID <•: :LBLC13 ST JDOC23 / •- EXP :ST0REC23); 

IFST = ".IF" EXP ".THEN" ST (".ELSE" ST JSIFTEC33 / .EMPTY :SIFTC23>; 

IvHILEST = ".WHILE" EXP ".DO" ST *WHLC23; 

FORST = M .FOR" \7AR •«- EXP ".BY" EXP ".TO" EXP ".DO" ST IFORC53; 

GOST = ".GO" ".TO" .ID :G0C13; 

IOST = ".OPEN" ("INPUT" .ID f C .ID »3 X0PNINPC23 / 

"OUTPUT" .ID 'C .ID '3 :OPNOUTC23> / 

".CLOSE" .ID :CLSFILC13 / 

".READ" .ID •: IDLIST IBRS38C23 / 

".INPUT" .ID •: IDLIST XXCIOC23 / 

".WRITE" .ID •: WLIST 10UTNUMC23 / 

".OUTPUT" .ID •: WLIST IOUTCARC23 ; 
IDLIST = VAR (IDLIST :D0C23 / .EMPTY); 

VJLIST = (.ID / .NUM / .SR) (WLIST :D0C23 / .EMPTY); 

BLOCK = ".BEGIN" ST $(•; ST : DOC 23) ".END"; 

EXP = ".IF" EXP ".THEN" EXP ".ELSE" EXP :AIFC33 / UNION; 

UNION = INTERSECTION ( f \V UNION :ORC23 / .EMPTY); 

INTERSECTION = NEG ( •& INTERSECTION :ANDC23 / .EMPTY); 

NEG = "NOT " NEGNE6 / RELATION; 

NEGNEG = "NOT " NEG / RELATION :N0TC13; 

RELATION = SUM(( "<=" SUM :LE / 

"<" SUM :LT / 
">=" SUM :GE / 
">" SUM :GT / 
"=" SUM :EQ / 
•# SUM :NE ) C23 / .EMPTY); 
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SUM = TERM ((•+ SUM t ADD/ •- SUM :SUB)C23/ .EMPTY); 

TERM = FACTOR <<•* TERM JMULT/V TERM 1 DIVI D/ •? TERM tREM)C23/. EMPTY); 

FACTOR a •- FACTOR :MINUSC 13 / •+ FACTOR / PRIMARY; 

PRIMARY = VARIABLE / CONSTANT / •( EXP •); 

VARIABLE = .ID S7ARC 13; 

CONSTANT = .NUM :CONC13; 

SIFTEC-#-*-3 => LOPRC*l##l##23 BRFC*1*#23 #1,"EQU *"\ *2 SIFTE1C #2* *33 ; 

SIFTEU#l#-3 => #"BRU , S#2\ #W"EGU *"\ *2 #2# M EQU *"\; 

SIFTC-*-3 => LOPRC*l*#l##23 BRFC*1##23 #1*"EQU * M \ *2 #2* "EQU *"\; 

WHLC-,-3 => #1, M EQU *"\ WHL1C*1,#23 *2 # M BRU"##1\ #2#"EQU *"\; 

V;KLlC-*#23 => LOPRC*l*#l>#23 BRFC*1##23 #1# M EQU *"\; 

GOC-3 => *"BRU M #*1\; 

FORC-, -,-.,-., -3 => <"DO NOT USE FOR STATEMENTS"^ 

LBLC-3 => *1*"EQU *"; 

AIFC-,-,-3 => LOPRC*l,#l>#23 BRFC*1*#23 #1,"EQU*"\ ACCC*23 AIF1C#2,*33; 

AIF1C#1j-3 => ,"BRU*S#2\ #1# M EQU *"\ ACCC*23 #2* W EQU *"\; 

LOPRCORC-#-3# #l#-3 => LOPRC * 1 :* Is # \, #23 BRTC* 1 :* \* # 13 

#2*"EQU *"\ L0PRC*l:*2, #1#*33 

CANDC-#-3#~,#13 => LOPRC*l:*l##2##13 BRFC * 1 1 * 1, #13 

#2*"EQU *"\ LOPRC*l:*2#*2*#13 

CNOTC-3##l, #23 => LOPRC*l:*l##2>#13 

C-*-#-3 => .empty; 

BRTCORC-,-3,#13 => BRTC * 1 :*2* # 13 
CANDC-*-3# #13 => BRTC*1:*2.»#13 

CNOTC-3##13 = > BRFC*1:*1*#13 

CLEC-*-3##13 = > BLEC*1:*1**1;*2>#13 

CLTC-,-3##13 = > BLTC*1:*1**1:*2##13 

CEQC-*-3*#13 => BEQC*lt*l**l:*2*#13 

C6EC-#-3##13 => BGET*1:*1,*1:*2>#13 

CGTC-,-3,#13 => BLEC*l:*2,*l:*l*#13 

CNEC-*-3##13 => BNEC*lf*l#*l:*2,#13 

C-,#13 => ACCC*13 ,"SKE =0"\ ,"BRU'S#1\; 

BRF[ORC-,-3,#13 => BRFC* 1 : *2# # 13 
CANDC-j-3* #13 => BRFC*lt*2*#13 
CNOTC-3##13 => BRTC*1:*U#13 
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CLEC-#-3*#13 => BLEC*lt*2#*l:*U#U 

CLTC-*-3*#13 => BGEC*1:*1**X:*2j#13 

CEQC-#-3##13 => BNEC*lt*W*l:*2*#13 

CGEC-#-3*#13 => BLTC*l:*l**lS*2##13 

CGTC-#-3*#13 => BLEC*l:*l**l:*2*#13 

CNEC-,-3##n => BEQC*ll*l**lJ*2##13 

C-,#13 => ACCC*13 *"SKA = -l"\ ,"BRU"##1\; 

BLTC-,->#13 => CT0KENC*13 ACCC*23 » "SKE", * 1\# "SKG"* * 1\ / 

W0RKC*13 ACCC*23 , "SKE'S "T+". W\# "SKG'S "T+". W-W\ > 
* "BRU *+2"\ , "BRU"##1\; 

BLEC-,->#13 = > (TOKENC*23 ACCC*13 # "SKG'S *2\ / 

T0KENC*13 ACCt*23 * "SKG"* * \\» "BRU *+2"\ / 

WORKC*23 ACCC*13 , "SKG'S "T+". W-W\ ) 
,"BRU'S#1\; 

BEGC-#-*#13 => CT0KENC*23 ACCC*13 *"SKE"#*2\ / 

T0KENC*13 ACCC*23 *"SKE", *1\ / 
WORKC*23 ACCC*13 , "SKE'S "T+". W- W\ ) 
#"BRU *+2"\ *"BkU"*#l\; 

BGEC-»-##13 => CT0KENC*13 ACCC*23 # "SHE'S * \\* "SKG'S * 1\ / 

W0RKC*13 ACCC*23 » "SKE'% "T+". W\# "SKG"* "T+". W-\v\ ) 
,"BRU"*#1\; 

BNEC-*-*#13 = > (TOKENC*23 ACCt*13 » "SKE"# *2\ / 

TOKENC*n ACCC*23 #"SKE">*1\ / 

WORKC*23 ACCC*13 » "SKE'S "T+". W- W\ ) 

,"BRU"##1\; 

STOhEC-*VARC*13 3 => "*ITS ALREADY THERE"\ 

C-.»ADDCVARC*13,CONC"l"3 3 3 => #"MIN">*!\ 
C-*ADDCVARC*13,-3 3 => ACCC*2:*23 ,"ADM"**i\ 

C--»SUBCVARC*13#-33 => ACCC*2:*23 , "CNA; ADM "*1\ 

C-*-3 => BREGC*23 *"STB"#*1\ / 

ACCC*23 *"STA"**1\; 
ADDCMINUSC-3*-3 => SUBC *2# * 1 : * 13 

C-,-3 => TOKENC*23 ACCC*13 , "ADD",*2\ / 

W0RKC*13 ACCC*23 » "ADD"* "T+". W- W\; 

SUBC-#-3 => T0KENC*23 ACCC*13 ,"SUB'S*2\ / 

T0KENO13 (BREGC*23 » "CBA; CNA; ADD "*1\ / 

ACCC*23 *"CNA; ADD "*1\) / 
W0RKO23 ACCC*13 * "SUB", "T+". W-W\i 

MINUSC-3 => T0KENC*13 *"LDA">*1\ ,"CNA"\ / 
BREGC*13 ,"CBA; CNA"\ / 
ACCC*13 , "CNA"\; 

DIVIDC-,-3 => T0KENC*23 CBREGC*13 , "CBA"\ / 

ACCC*13) , "RSH 23; DIV "*2\ / 
WORKC*23 CBREGC*13 *"CBA"\ / 

ACCC*13) , "RSH 23; DIV T+".V-W\; 



D— 14 



BREGCMULTi>#-3 3 => T0KENC*ll*23 ACCC*1:*13 * "MUL M # * 1 : *2 M ; RSH 1"\ / 

T0KENC*1:*13 ACCC*1:*23 » "MUL M #*ll* 1"; RSH 1"\ / 
W0RKC*lf*13 ACCC*1:*23 # "MUL"# M T+".W-W"; RSH 1"\ 
CREMC-#-33 => T0KHNC*1:*23 <BREGC*lt*13 ,"CBA"\ / 

ACCC*13> *"RSH 23; DIV "*1:*2\ / 
W0RKC*l2*23 <BREGC*ti*13 » "CBA"\ / 

ACCC* 15*13) ,"RSH 23; DIV T+" 

• w-w M ; rsh i M \; 

ACCC-3 => T0KENC*13 , "LDA"**1\ / 
BREGC*13 # f, CBA M \ / 

*i; 

W0RKC-3 *> BREGC*13 » "STB"* "T+"+W\ / 
ACCC*13 #"STA"* ,, T+"+W\; 

T0KENCV/ARCID3 3 => • EMPTY 

CCONCNUM3 3 => .EMPTY; 

MULT / => .empty; 

REM / => .empty; 

and / => .empty; 

or / => .empty; 

not / => .empty; 

ENDN / => "T"*"BSS"*tW\ *"END"\; 
VARCID3 => *i; 
C0NCNUM3 => '= *i; 

LE / => .empty; 
lt / => .empty; 
eg / => .empty; 
ge / => .empty; 
gt / => .empty; 
ne / => .empty; 

DOC-*- 3 => *1 *2; 

OPNINPC-#-3 => * "clear; brs is; BRU "*2"; BRS 16; BRU "*2"; STA "*i\; 

0PN0UTC-*-3 => , "CLEAR; BRS 18; BRU "*2"; LDX =3; BRS 19; BRU " 

*2"; sta "*i\; 
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CLSFILC-3 => ,"LDA "* 1"; BRS 20"\; 

BRS38C-,.ID3 => *"LDA "* 1"; LDB = 10; BRS 38; STA M *2\ 
C-..-3 => BRS38C*1**2:*13 BRS38C* 1> *2: *23 ; 

XCI0C-*.ID3 => ,"CIO "*1"; STA °*2\ 

C-#-3 => XCI0C*1**2:*13 XCI0C*l#*2t*23; 

0UTCARC-.fID3 => *"LDA "*2"; CIO "*1\ 

C-,.NUM3 => *"LDA = "*2"; CIO "*1\ 

C-J.SR3 => #"LDA = "#1"; LDB ="*2:L"; LDX "*1"; BRS 36; BRU "*2\ 

#1*"ASC "• , *2 f '\ 
C-,-3 => OUTCARC*l**2:*13 OUTCARC* 1* *2s*23; 

OUTNUMC-#.ID3 => ,"LDA M *l"; LDA = 10; BRS 38; M \ 
C-*.NUM3 => #"LDA = "*2"; CIO M *l\ 
C-,.SR3 => *"LDA ="#1"; LDB ="*2:L"; LDX "*1"; BRS 36; BRU "*2\ 

#1,"ASC M,, *2 ,, \ 
C-,-3 => OUTNUMC*l#*2J*13 OUTNUMC* 1* *2: *23; 

STARTN / => "START"* "EQU"*"*"\; 

DECNCID3 => *1*"BSS 1"\ 

C-3 => DECNC*1:*13 DECNC*l:*23 ; 

• END 
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• META PROGRM 



%5% 



PROGRM = ".META" .ID ? 1? <"META II 1.1"> 

C" NOLIST EXT* NUL;$ START BRM INITL"3 

C"$KSTKSZ EQU l;$MSTKSZ EQU 100;$NSTXSZ EQU \i SSSSIZE EQU 550"3 
C".LIST" C*"CLA; STA LISTFG"3 / .EMPTY) 
C#"BRM RLINE; BRM "*"; BRM FINISH"3 
(•< SIZ $<S SIZ) •) ?17E / .EMPTY) 

$ST ".END" ?2E 
C"STAR BSS liSSTOP DATA SS+SSSIZE- 5; $SS BSS SSSIZE"3 
C"$MSP DATA MSTK;$MSPT DATA MSTK+MSTKSZ- 5; SMSTK BSS MSTKSZ"3 
C"$NSP DATA NSTK;SNSPT DATA NSTK+NSTKSZ- 5; SNSTK BSS NSTKSZ"3 
C"$KSP DATA KSTK;$KSPT DATA KSTK+KSTKSZ- 5; SKSTK BSS KSTKSZ"3 
C*"END"3 <"DOME">; 

.ID '= ?3E <"ST"> C**"ZRO; LDA *-i; BRM CLL"3 
EXP ?4E •; ?5E C#"BRU RTN"3; 
SUBEXP $(•/ C*"LDA MFLAG; SKE =0; BRU "* 1 3 

SUBEXP) C*1*"EQU *"3; 

(GEN / ELT C, "LDA MFLAG; SKE si; BRU "* 1 3 ) 

SREST C*1,"EQU *"3; 
GEN / ELT C,"LDA MFLAG; SKE =0; BRU *+4"3 

<•? .NUM ? 12E C*"LDA ="*"; BRM ERR"3 

(.ID C*"BRM",*3/ •? C*"BRS EXI T"3 )? 1 3E/ 

.EMPTY C"CLA; BRM ERR; BRS EXIT"3); 
•ID ?6E C*"BRM"**"; STA STAR"3 / 
. ID C#"BRM",*3/ 

• SR C*"BRM tst; DATA "*L"; ASC ••••♦••3 / 
•( EXP ?7E ') ?8E / 
•• .CHR C*"LDA ="*N"; BRM TCH"3; 
C $OUT '3 ?10E C"BRM CRLF"3 / 

•S C*1#"EQU *"3 ELT ?9E 

C,"LDA MFLAG; SKE =0; BRU "*1"; MIN MFLAG"3 / 
"•EMPTY" C#"LDA =i; STA MFLAG"3 / 

LDA* IWP; STA STAR; MIN NCCP"3 / 
DATA "*L"J ASC "••*••"; BRM CRLFT"J 



ST = 
EXP = 
SUBEXP 
REST a 

ELT = 



GEN = 



OUT = 



BRU *+35 MIN NCCP; BRU "*13/ 



•* 



E = => 
SIZ = 



".CHR" C#"BRM V/PREP; BRM INC; 
. SR ?12E '> ?13E C#"BRM LITT; 
•=>" C*1,"EQU *"3 ELT ?14E 

C*"LDA MFLAG; SKE -0; 
• ! .SR ? 15E C,*3; 
. SR C#"BRM LIT; DATA "*L"; ASC 
C*"BRM TAB" 3 / 

(.num c,"lda = 47b; cio fnumo; min chno; lda 
*"; brm genlab; sta gn"*"; brm outn"3 / 
•l c*"lda* star! brm 0utn"3 / 

•N C#"LDA STAR; BRM 0UTN"3 / 

•C C#"LDA STAR; CIO FNUMO; MIN CHN0"3 / 

•EMPTY C#"LDA STAR; BRM 0UTS"3 )/ 

•• .CHR C*"LDA = "*N"; CIO FNUMO; MIN CHN0"3/ 

•: C#"BRM CRLF"3; 

'; C#"BRU RTN"3 $ST ".END" 

"K=" .NUM C"$KSTKSZ EQU "*3 

"M=" .NUM C"SMSTKSZ EQU "*3 

"N=" .NUM C"$NSTKSZ EQU "*3 

"S=" .NUM C"$SSSIZE EQU "*3; 
• END 



GN 



•« 



? HE 
/ 
/ 
/ 



C#"END"3 FINISH; 
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• META PROGKM %TREE 1«3X 

PROGRM = (".META" .ID ? 1? (".LIST" JLISTC03/ .EMPTY 5MTC03) SIZE 
:BEGINC33 / 

".CONTINUE" :MTC03 ) <"TREE 1.3"> :SETUPC13 * S< RULE * ) 
".END" ?2E :ENDNC03 * <"DONE">; 

SIZE = •( SIZ $(•# SIZ :D0C23) •) ? 50E / .EMPTY *MTC03; 

SI?' = .CHR •= ?54E .NUM ? 55E :SIZSC23; 

RULE = .ID 

( •« EXP ?3E ( •« :KP0PKC13 / .EMPTY) JOUTPTC23 / 
•/ »«>» ?3E GEN1 IS1MPC23 / 
OUTRTJL :OUTPTC23) ?5E •; ?6E ; 

EXP = '«- SUBACK ?7E ( •/ EXP ?8E :BALTERC23 / .EMPTY :BALTERC13) / 
SUB EXP (V EXP ?9E 5ALTERC23/ .EMPTY); 

SUBACK = NTEST < SUBACK : DOC 23 / .EMPTY) / 
STEST (SUBACK JC0NCATC23 / .EMPTY); 

SUBEXP = (NTEST / STEST) (NOBACK tCONCATC23 / .EMPTY); 

NOBACK = (NTEST / STEST ( •? .NUM ? 10E :LOADC 13 (.ID / •? :ZK0C03) ?11E 
:ERCODC33 / .EMPTY :ERC13) ) 
(NOBACK : DOC 23 / .EMPTY); 

NTEST = f * .ID ?12E INDLBC 13 / 

•C ( .NUM '3 ?14E :MKNODEC13 / 

GENP '3 ?52E (»t/. EMPTY 80UTCRC03 IDOC23) ) / 
•< GENP •> ?53E (•? /.EMPTY :OUTCRC03 IDOC23) JTTYC13 / 

(".CHR" tGCHR / 
•* :G0) C03 / 

"=>•• stest ?15e sscanc13 / 
comm; 

GENP s GENPl / .EMPTY :MTC03; 

GENP1 = GENP2 (GENPl : DOC 23 / .EMPTY); 

GENP2 = '* CS .NUM ?51E :PAR0UTC13 / .EMPTY :ZR0C03 xPAROUTCU) 
(•L :0L / 'C tOC / - N xON / .EMPTY *0S)C03 :N0PTC23/ GENU; 

COMM = ".EMPTY" : SETC 03 / 

• ! .SR ? 18E :IMEDC 13; 

STEST = '. .ID ?19E 8PRIMC13 / 
.ID :CALLC 13/ 
•SR :STSTC 13 / 
•( EXP ?20E •) ?21E / 
•• .CHR :CTSTC 13/ 
(.NUM •$ ?23E /•$ :ZR0C03) (.NUM /.EMPTY :MTC03) STEST ? 24E SARBC33/ 
•- (.SR JNSRC13 / •• .CHR :NCHRCl3) ?26E :NTSTC13; 
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OUTRUL = 'C OUTR ?27E COUTRUL JALTERC23 / .EMPTY) 10SETC13; 

OUTR = OUTEST "=>" ? 29E OUTEXP ? 30E IC0NCATC23; 

OUTEST = ( (•] :MT / "-3" *ONE / ••-,-]" : TVO / "->->-3" :THRE> C03 / 

ITEMS '3 ) iCNTCKCU; 

ITEMS = ITEM (V# ITEMS ?32E HTMSTRC23 / .EMPTY :LITEMC13) % 

ITEM = •- :MTC03 / 

• ID »C 733E OUTEST ? 34E JRITEMC23/ 

NSIMP1 INITEMC 13 / 

•• .ID ?35E IFITEMC13 / 

•SR STTSTC 13 / 

•• .CHR ICHTSTC13 / 

•# .NUM ?37E :GNITEMC13; 

OUTEXP = SUBOUT ( V OUTEXP IALTERC23 / .EMPTY); 

SUBOUT = OUTT CREST :CONCATC23 / .EMPTY) / REST; 

REST = OUTT <REST :OERC23/ .EMPTY) / GEN (REST :DOC23/ .EMPTY); 

OUTT = .ID «C ?39E ARGLST '3 ? 40E :0UTCLLC23 / '( OUTEXP •) ?41E / 
NSIMP1 CM (»S :OS / *L :OL / - N :ON/ »C :0C)CO3 :NOPTC23 / 
• EMPTY 2DOITC 13); 

ARGLST = ARGMNT XARGC13 ( '* ARGLST XD0C23 / .EMPTY) / .EMPTY $MTC03; 

ARGMNT = NSIMP :ARGLDC13 / •# .NUM :GENARGC13; 

NSIMP1 = - M NSIMP SUPC23 / NSIMP :LKTC131 

NSIMP = •* .NUM (~ ': NSIMP J CHASEC 23 / .EMPTY *LCHASEt 1 3 ); 

GEN1 = (OUT/COMM) (GEN1 t DOC 23 / .EMPTY); 

GEN = COMM / GENU / •< I TTYC 03 / •> XFILC03; 

GENU = OUT / 

•• .ID ?42E 'C ?43E ((.ID / .NUM) :LOADC 13 JCALLC23 / 

• EMPTY :CALLC13) f 3 / 
•# .NUM SGNLBLC13 (M :DEFC13 / .EMPTY) ; 

OUT = ( »\ lOUTCR / '# :OUTAB) C 03 / 
•SR :0UTSRC13 / 
•• .CHR :OUTCHC 13 / 
"+W" tUPWRKC03 :0UTWRKC13 / 
"-W" :DWNWRKC03 / 
".W" JMTC03 5 0UTVRK / 
•t f W 2MAXWRKC03; 

E = .EMPTY RESET => •; $( RULE * ) ".END" 799E FINISH; 
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%OUT RULES% 

SETUP C-3 => #"N0LIST NUL,EXT;GEN OPD 101B5#1j1;BF OPD 102B5#1#1"\ 
"BT OPD 103B5* \* UPSHN OPD 104B5# 1 » II PSHK OPD 105B5# \» 1"\ 
"MKND OPD 106B5* 1# WNDLBL OPD 107B5* 1# i; GET OPD 110B5*1*1"\ 
"BPTR OPD 111B5* 1> WBNPTR OPD 1 12B5# \» \i RI 1 OPD 113B5#1#1"\ 
"RI2 OPD 114B5#2;FLGT OPD li5B5#l#i;BE OPD U6B5#1*1"\ 
"LAB OPD 117B5>l*i;CE OPD 120B5* 1# ULDKA OPD 121B5#1#1"\ 
"SKSTKSZ EQU 100; SMSTKSZ EQU 130; SNSTKSZ EOU 13005 SSSTKSZ EQU 1400"\ 

*i; 

BEGINC-#-*-J => "SSTART BRM INITL; CLA; STA WRK; STA XVRK"\ *3 *2 
,"BRM RLINE; BRM "*1"; BRM FINISH"\; 

LIST / => " CLA; STA LISTF6J"; 

0UTPTO*-3 => *l:S ,"ZR0; LDA *-i; BRM CLL0"\ *2 ,"BRU RTNO"\; 

SIMPC-#-3 => *1 ,"ZRO"\ *2 #"BRR "*1\; 

BALTERC-3 => ,"BRM SAV"\ *1 » "BRM RSTR"\ 

C-,-3 => ,"BRM SAV"\ *1 /"BRM RSTR; BT "#1\ *2 #1.DC3; 

D / => *"EQU *"\; 

ALTERO* SETC3 3 = > * 1 *2 

CC0NCATl>#-3#-3 = >PMTC*1:*1*#13 *lt*2 *"BRU "#2\ #NDC3 *2 #2.DC3 
t-,-3 => *1 *"BT "#1\ *2 #WDC3; 

PMTCPRIMC-3>#13 => * "BRM "*1:*1:S"; BF "#1"; MRG "* 1 : * 1 : S"FLG; PSHK =0"\ 
C-,-3 => *1 *"BF "#1\; 

ERCALTERC-#SETC3 33 => *1 

c-3 => *i *"be =-i"\; 

D0C-#-3 => *i *2; 

CONCATC-,-3 => *1 #"BF "#1\ *2 #1«DC3; 

L0ADC.NUM3 => ,"LDA ="*1:S\ 

CID3 => #"LDA "*l:S\; 

CALLC-3 => ,"BRM "*1\ 

C-,-3 => *2 ,"BRM "*1\; 

MT / => .empty; 
CLA / => "CLA"; 

zro / => "o"; 
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FKC0DC-#-,-3 *> *l *2 #"BF "*3\t 

NDLBC-3 => #"NDLBL ="*1\; 

MKNODEC-3 => # M MKND = "*1\; 

AKBCZROC3#MTC3#-3 => # 1 . DC 3 *3#"BT "#1"J MIN MFLAG"\ 
CNUM#MTC3*-3 «> ARB1C*13 # 1 . DC 3 *3 

,"SKR* MSP; BT M #l"l SKN* MSP* BRU *+3; BT "#l"i MIN MFLAG"\ 
•ARB3C3 
C-#.NUM#-3 => ARB1C*23 #l.DC3 *3 

#"SKR* MSP; BT M #l"; SKN* MSP"\ ARB2C*1#*23; 

AKB1C-3 => #"BRM SAV; LDA »"*HS"+i; MIN MSP; STA* MSP"\; 

AHDCC-*.NUM3 => #"BKU *+45 CLA; STA MFLAG; BRU *+4; LDA* MSP; SKG = M *2 

"-"* 1"; MIN MFLAG"\ .ARB3C3 
C-3 => #"BRU *+3; CLA ; STA MFLAG" \ .ARB3C3; 

ARB3 / => #"LDA s-lJ ADM MSP; BRM RSTR"\; 

6CHR / = > ,"BRM WPREP; BRM INC; LDA* IWP; MRG CHRFLG; MIN NCCP; PSHK = 0"! 

GO / => , "BRM OUTREE; BT *+3; LDA =2; BRM CFRR"\* 

SET / => #"LDA =i; STA MFLAG"\; 

TTYC-3 => TTYC3 *1 FILC3 

C3 => #"LDA =i; STA FNUMO"\ XCHCHC 3 ; 

FILC] => *"LDA XFNUMO; STA FNUMO"\; 

XCHCH/ => , "LDA TCHNO; XMA CHNO; STA TCHNO"\; 

STRINGC-3 => " DATA "*1:L"; ASC " ,, *1 ,, \; 

OSETC-3 => *"BRM BEGN"\ *1J 

CNTCKC-3 => *1 , "CLB; SKE NCNT; STB MFLAG"\; 

ONE / => , "LDA =1 M \; 

TV'O / a> ,"LDA =2 M \; 

1HPE / => *"LDA =3"\; 

ITWSTR C-*-3 => *1 #"MIN CNT; EAX - 1# 2"\ *2; 

LITEM C-3 => *1 #"MIN CNT; LDA CNT M \; 

RITEMC-#-3 => j"RI1 ="*1"; BRU "♦IN *2 >"RI2"\ #1.DC3; 

0EhC-.»-3 => *1# "CE = 1"\ *2; 
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outcll c-,-3 => #"lda nsp; sta snsp; ndlbl = "*1"; cla; sta cnt"\ 

#"lda kt; sta me"\ *2 
, "mknd cnt; pshn snsp; ldx kt; brm* 0*2; brm popk"\ 
#"lda* nsp; sta nsp"\; 

ARGLDC-3 => * #, LDA ME"\ *U 

ARG C-3 => *1 # M PSHK =0; MIN CNT"\; 

CHASE C-#-3 => , "GET = "*1"; BPTR *+3; LDA =3; BRM CERR"\ *2; 

LCHASE C-3 => #"GET ="*1\; 

DOI'l C-3 => *1 , "BNPTR "#1 

"; cax; pshk = o; brm* o#2; brm popk; bru *+2 m \ 
#i.pc3 # m brm outs"\; 

NOPT C-*-3 => *1 #"BNPTR *+3; LDA = 4; BRM CERR; " *2; 

SCAN C-3 => #1.DC3 *1 , "BT *+3; MIN NCCP; BRU "#1\; 

PRIM C-3 => *"BRM "*1"; BF *+3; MRG "*r»FLG; PSHK = 0"\; 

STST C-3 => *"BRM TST; M STRINGC*13; 

CTST C-3 => #"LDA = "*1:N"; BRM TCH"\J 

OS / => " BRM OUTS"\; 

ON / => " ETR =77777B; BRM OUTN M \; 

OL / =>' " CAX; LDA 0*2; BRM OUTN°\J 

OC / => " ETR =377B; CIO FNUMO; MIN CHNO"\; 

GNLBL C-3 => # M GEN GNLB"* 1\; 

DEF C-3 => *1 , "BRM LIT; DATA 6; ASC "•••• EQU * ,,,f \; 

OL'TCR / => #"BRM CRLF"\; 

OUTAB / => #"BRM TAB"\; 

OUTSR C-3 => #"BRM LIT; " STRINGC*13; 

OUTCH C-3 => #"LDA ="*1:N"; CIO FNUMO; MIN CHNO"\; 

ENDN / => M SSTOP DATA SS+SSTKSZ- 5; $SS BSS SSTKSZ"\ 

"MSP DATA MSTK;$MSPT DATA MSTK+MSTKSZ- 5; SMSTK BSS MSTKSZ"\ 
"NSP DATA NSTK;$NSPT DATA NSTK+NSTKSZ- 5; SNSTK BSS NSTKSZ"\ 
"KSP DATA KSTK;$KSPT DATA KSTK+KSTKSZ- 5; SKSTK BSS KSTKSZ"\ 
"WRK BSS i;XWRK BSS \l END"\; 

SAVG C-3 => *"BRM SAVGN"\ *1 * M BRM RSTGN"\; 
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IMED C-3 *> ,*1\$ 

NITBMC-3 => #"STX INDX; LDA KT M \ *1 

#"CLB; ldx indx; ske 0,2; stb mflag m \; 

FITEMC-3 => ,"FLGT M * 1 t S"FLG M \; 

TTSTC-3 => # M BRM SSTEST; " STRlNGC*13; 

CHTSTC-3 => #"CLB; LDA ="*UN"; MRG CHRFLG; SKE 0# 2i STB MFLAG"\; 

GNITEMC-3 => #"FLGT GENFLG; ETR =77777B; STA GNLB"*lxS\; 

GENARGC-3 *> » "LAB GNLB"* 1 : S"i MRG GENFLG"\; 

NTSTC-3 => #"LDA NCCPJ STA SNCCP"\ *1 

,"LDA = i; SKR MFLAGI BRU *+2i STA MFLAG; LDA SNCCP; STA NCCP"\; 

NCHRC-] => #"LDA ="*ltN M ; BRM TCH"\; 

NSRC-3 => # M BRM tst; "STRINGC * 1 3; 

UPC M l"*-3 => #"LDA* KSP"\ *2 

C-,-3 =*> #"LDX KSPi LDA 1-"*1:S"*2"\ *2; 

LKTC-3 => , "LDA KT"\ * l; 

UPWRK / => ,"MIN WRK; LDA WRKi SKG XVRK; LDA XWRK; STA XWRK"\; 
DWNlvRK / => #"LDA =- l; ADM V'RK"\; 
OUTVJRKC-3 => *1, "LDA WRK; BRM OUTN"\; 
MAXWRK / => , "LDA XWRK; BRM OUTN"\; 
SIZSCCHR#-3 => *1:C"STKSZ EQU "*2:S\; 

KPOPKC-3 => , "MIN MSP; LDA Kit STA* MSP; MIN MSP; LDA KSP; STA* MSP"\ 

*1 #"LDX MSP; LDA 0# 2; STA KSP; LDA -1,2; STA KT; LDA «-2; ADM MSP"\; 

PAROUTCZROC3 3 => ,"LDA KT"\ 
C"0"3 => #"LDA KT"\ 
C-3 => , "LDKA = M *1\; 

• END 
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